Summary

Adds a new /speckit.amend command that enables targeted spec amendments after implementation is complete. This fills a gap in the current workflow where discovering a missing edge case post-implementation requires either manual edits (breaking spec-first principle) or re-running the full pipeline unnecessarily.

Problem

The current spec-kit workflow is linear:

/speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement

This works well for initial development. But after implementation, two common scenarios have no dedicated workflow:

1. Post-implementation edge case: A missing behavior is discovered in production, during review, or through testing
2. Behavioral correction: An existing scenario needs modification after the feature is shipped

Today, users must either:

• Manually edit spec, tests, and code (breaks spec-first principle, creates drift)
• Re-run /speckit.clarify + /speckit.tasks + /speckit.implement (overkill for a single scenario)

Solution

/speckit.amend is a targeted micro-cycle that cascades a single amendment through all artifacts:

/speckit.amend "empty string IDs should be treated as null"
    │
    ├── Phase 1: Load context (spec, plan, tasks)
    ├── Phase 2: Update spec.md (clarification + acceptance scenario + edge case)
    ├── Phase 3: Locate affected test and implementation files
    ├── Phase 4: Add failing test (RED)
    ├── Phase 5: Make targeted code change (GREEN)
    └── Phase 6: Update tasks.md traceability

Design Principles

• Spec is always first: Never modifies tests or code before updating spec.md
• Minimal blast radius: Only touches files directly affected by the amendment
• Test before implement: Follows RED → GREEN cycle for the new scenario
• One amendment per invocation: Keeps changes focused and reviewable
• User confirmation: Presents an impact map before making changes
• Fail-safe: Halts cleanly if any phase encounters an error

How It Fits the Workflow

/speckit.specify  →  Initial feature creation
/speckit.clarify  →  Pre-implementation refinement
/speckit.plan     →  Technical planning
/speckit.tasks    →  Task generation
/speckit.implement → Execution
/speckit.amend    →  Post-implementation amendments (NEW)
/speckit.analyze  →  Consistency verification

Command Patterns Followed

• Standard YAML frontmatter with description, handoffs, scripts
• Uses check-prerequisites.sh --json --require-tasks --include-tasks (same as /speckit.implement and /speckit.analyze)
• Standard ## User Input / ## Outline body structure
• {SCRIPT} and {ARGS} placeholders for multi-agent compatibility
• Technology-agnostic (works with any testing framework — pytest, jest, rspec, junit, etc.)
• Hands off to /speckit.analyze for post-amendment consistency check

AI Disclosure

This PR was developed collaboratively with Claude Opus 4.6. The command was designed through iterative discussion about BDD (Behavior-Driven Development) integration with spec-driven development, specifically around how to handle post-implementation edge case discovery. The author has reviewed, tested the design against existing spec-kit command patterns, and understands the full implementation.

Test Plan

• Verify the command file follows the exact frontmatter schema used by other commands
• Test with specify init to ensure the command is picked up and distributed to agents
• Run a sample /speckit.amend on a project that has completed /speckit.implement
• Verify spec.md is updated with Amendment section (not Clarification session)
• Verify tasks.md gets a "Post-Implementation Amendments" section
• Verify the handoff to /speckit.analyze works after amendment
• Test the guard: running on a project with no completed tasks should warn and suggest /speckit.clarify